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ANTE ODE TTON 


The aoa) of the „Naval Postagracduater School Signal 
Processing and Display Laboratory is to provide a facility 
for research and education in the field of computer science. 
The laboratory is built around a pair of Diaital Equipment 
Menrporation PDP-11/50 processors. One processor iS 
primarily used to service multiuser orogram develocment 
activities. The other orocessor suoports several graphics 
aisolay devices ana orovides a dedicated environment for 
research and develooment in the areas of operatina svsters, 
comouter araphics and signal orocessing. Figure 1 shows the 
present hardware configuration of the laboratory. 


The UNIX operatine system Mae, 3 time=-snarina system 


developed at Fel) Laboratories, was chosen as the system 
best suited to supoort the goals stated above. UNIX'sS 
inherent file system flexibility and the availability of 


System source coge written in the high level prograrmina 
language» es orcvide an excellent environment for 
operating system development and research. The availanility 
of a dedicated processor as a developmental tool further 
enhances this environment. 

Due to the unique and demanding requirements placed on 
the diselay processor's ocerating system by gracnics devices 
ana signal orocessing equipment, itt was aeternined tnat tne 


standard version of UNIX in use ( henceforth sırp!y referren 





to as UNIX ) was unsatisfactory. This thesis proooses an 
extension to the UNIX system in the form of a new memory 
management scheme. The approach taken was to implement 
process segmentation with provision for data space 
allocation and alignment within a specified memory region. 
This approach was feasible and attractive because the 
PDP-11/50 is equiopea with a memory management unit (MMU) 
that suoports seamentation. Aaditionally, segmentation 
provides extra flexibility in resident orocess manioulation. 
UNIX allocates process soace as a single contiguous unit in 
main memory. Seamentation allows management of orocess 
segments as separate entities. This provides the necessary 
tool for selective allocation of memory soace ee an 
individual seament. 

This latter feature is particularly attractive in a 
System confiaured with multiported memory. As shown in 
Figure 1, the gisolay processor has access to two dual- 
ported memory areas? one shared with a sianal processina 
controller, the other shared with a slave processor for the 
refresh araphics display devices. Due to the real-time 


requirements of these devices, independent access to data in 


the shared reaion is necessary. Otherwise, the display 
processor will mot be able to support multiproarammıng. A 
segmented memory raracer would provide the features 


necessary to sucport these real-time recuirements. 
iweumocltricat tons. of the UNIX operatina system were 
implemented and testeo as » Pesult of this thesis. One was 


a previously designec (49), but unimolemented, seamented 
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memory manager version (SUNIX). The otner, a shared- 
segmented version (SSUNIX), was a further modification of 
SUNIX which implemented the alianment of a orocess's data 
soace within a shared memory reaion. Real-time processing 
was supported byv lockina the orocess image in main memory 
once the shared region had been acquired. 

Testing of SUNIX and SSUNTX included benchmark 
measurements and cperation in the general multiuser 
environment. Performance was almost identica! ton that Of 
UNIX. Additionally, SSUNIx was tested on the display 
processor and successfully fulfilled tne objective of data 
space alignment with system orotection. Amplification of 
aese results is brovidea in Chapter V of this thesis. A 
addition, recommendations are includea for aoplications and 
Bar zartıocn of SUNIX amd SSUNTX in the Siaqanal Processing and 


Disolay Laboratory. 
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Lie eA KGROUND 


A. PREVIOUS WORK 


Three previous thesis projects which are closely 
associated with the development of  SIUNIX ara SSUNIX are 
discussed below. It should be noted that a specific area of 
concern in all three papers is tne development of svstem 


Soc rt tor the soecia! devices on the display processor. 


l. Partitioned Segmented Memory Manacer 
In this thesis [4], Emery reports an investigation 
of the apolicability of sadaing ana segmentation to memory 
management in UNIX. Two memory managers were designed to 
support this investication: a oartitioned seamented version 
BUNT), and a simpler segmented version (SUNIX). The 


primary consideration in the design effort was that tne 


segments be separate and indeoendently manageable In main 
memory. The segmentation chosen was the existinc natural 
division into a process control Olocx», a data segmenr 


(includina non-sharec text), and a User stack. Shared text 
segments were handleg in mucn the same manner as in UNIX, 
SUNT x was designec to manace each complete secment 
ingependently. it was this design effort that provideg a 
moumdatiom for the development of SSUNIXA. PSUNIX further 
broke Der each of tne seaments into variable-siıze hlocks. 


Testing of PSUNTX was accomplished by usina 
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benchmark measurements to analyze its performance in 
relation fo UNIX. Tne experimental results zceieäriyv 
indicated that the performance of PSUNIX and UNIX were 
nearly identical over a wide range of available User memory 
space. Emery suggested that this approximate eauality of 
pergormance indicated that the disadvantage of the increased 
amount of swapping in PSUNIX was offset bv a reduction in 
the number of Drocesses sSwanped. He attributed tnis to 
reduced external fragmentation with PSUNIX. However, due to 
the relative complexity of PSUNTX, Emery recommends that the 
simoler SUNIX be comoleted and ımplementeo as a viable 


alternative. 


ec. Inter-Processcecr Graphics Support System 

Visco {12} investigated a multiola processor system 
confiauration to sueport a real-time, interactive graohics 
package. UNIX was recesiqaned to implement a real-time 
system call and a master-slave relationship between the 
disolay processor ard a dedicated graphics Processors 
moecyficallyv, he designed the system support routines 
necessary for integration of the PDP-11/50, PDP-11/34, and 
vector General (vC) Display Processors. Or RSS ca 
purposes, inter-processor communications were simulated on 
the PDP-11/50, since the PDP-11/34 slave orocessor was not 
available for use. 

The master-slave orocessor Cor Lrourat lon was 
conceiveo as an answer to the prooler of refresh graohnics 


devices havinc a hion level of direct memory access (OMA) 





requests and a reauirement for real-time system support. 
DMA is the transfer of data directly to or from memory by a 
peripheral device, without processor suoervision. This 
configuration required shared memory and the system support 
software to alian a process image in the snharec region. 
Memory management hardware on the slave processor (2] 
permitted a 32 tnousand (kK) word address range. The system 
designed oy Visco allocated the entire process imace on a 
32K word boundary. System orotection was not achieved since 
other processes „ere allowed to overlae into this region. 
Visco sugaested an imolementation of Erery's SUNIX 
as) a method of allocating only the graphics process's data 
space to the sharea region of memory. Since OMA by the 
slave crocessor, actina im cehalf of the grachics device, 
was hiahly concentrated in data soace, ERAS memory 
allocation scheme would more efficiently utilize the limited 
amount of shared memory. SSUNIX, with the added features of 
generalized multioorted memory apolications and system 


protection, was developed as a result of this sugaestior. 


3. Loosely=-Couoled Multiprocessor System 
Visco's work was directed primarily toward the main 
processor in the prooosed multiorocessor system for tne 
laboratory. A thesis by Gray [S] addresses the development 
of an operating system for the slave processor. Although 
not directly related to the orotlem of remory management in 
UNIX, this paper is mentioned here to emphasize the ceneral 


trena of thesis work cone in support of the aBboratarvı s 
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refresn graohics devices. Furthermore, recommendations in a 
later chapter of thecomipsaoers soeci fically adaress the 


integration of SSUNIX into the multiprocessor environment. 


B. GENERAL SYSTEM PROPOSAL 


Re indicated in the orevious section, the specific 
system proposed by this thesis was desianed primarily to 
perform data space alignment in a shared memory area for 
resident signal processina and refresh araphics processes. 
However, the actual modifications to UNIX were designed to 
offer more general agpelications. SUNIX was implemented as a 
general purpose operating system with secmented memory 
management. The differences between UNIX and SUNIY are 
transparent to the User. SSUNIX provides the ability to 
alian a process's data space within any given area of User 
memory space. Locatien and size nf this memory reaion, 
which was intended to correspond to shared memory assets, 
can Ne specified at svstem aeneration time. The limitations 
of UNIX in a system confiaured with devices which demand 
heavy DMA and real-time system support are discussed. Tne 
general CONC sio enind tre gesian of SUNITA and SSUNI*Y are 


also presented. 
I 


ie: nations tos, the Present System 


de bus Allocation 
As shown in Figure |, all Bere r1750 components 


and peripnerajls connect to and communicate with each other 





over a hiqhesoeed, bidirectional, asynchronous bus known as 
mene UNISUS 13]. Devices gain access to the UNIBUS via an 
Srbitration umit. This unit arants bus mastershin based on 
a multilevel priority scheme. Each device on the UNIBUS is 
assigned a hard-wired priority which is recoanizea by the 
eroicer. A device 1S aranted immediate mastersnip when a 
request 1S made and no device of equal or higher priority 
Nes control. DMA reauests from oerioheral devices have 
mramest priority. The central processing unit (CPU) has tne 
Capability to control or release the bus by varying its own 
priority level. This makes it possible for devices to 
access main memory with almost no processor intervention. 

Devices which require a  larae amount of DMA 
place heavy demands on the UNIBUS. A problem ar1ises in a 
multiprogrammina environment when a process is running at a 
high schedulina oriority (as with real-time orocesses)», and 
31so recuires high ertority and heavy bus utilization for 
DMA, In tnis case, all other orocesses are essentially 
pulsmeernded Since they cannot gain access to the LND O 
Refresh araphics devices require heavy bus utilization for 
processing the display list. In the case of tne VG devices 
in the laboratory, tne display list, located in the resicent 
graohics orocess's data space, must be processed every one- 
Mortieth of 3 second. It is thus necessary to lock the 
active display list ır memory. If the list were not in 
memory at the time of a refresh cycle an inorainate delay 
Seu G OCCU, CausiNna tne display to flicker- or fade. 


As noted previously, Gualenorteq memory was 


a 





conceived as a solution to these problems. Nith the 
peripheral processors each assigned a separate bus attached 
to memory ports ooposite the main processor, interference 
durina DMA could be virtually eliminated. The proolem which 
remained was the allocation of a process's data space to one 
of the shared memory areas. Visco's desian attemoted to 
solve this problem specifically for VG orocesses. SSUNI X 
was designed to solve the orodlem for more general 


seBolications, 


b. Memory Allocation Scheme 

Io UNIX; while the processor is executina in 
benalf of a process, its image must reside in main memory as 
nale contiquous unit. Unless swappina is necessary, the 
image remains in memory durina the execution of other 
processes. Nhen the CPU, is. executing a. (process, MMU 
registers are loaded so the process can access only its own 
image and» if applicable, 3 text segment shared with other 
processes. 

The memory allocation scheme used in UNIX is 
ase on a "first-fir" alaorithm. That is, the orocess 
mage is allocated spaces in the first free area in the 
system's free-list which can accomodate it. Mith this 
scheme, selective allocation and alignment of memory space 
MOS articular region of memory is inpossible. Tnis is 
unsatisfactory in a system configured witn multioorted 
memory. As an example, the Computer Sianal Processors 


WN OS Pastas controller can access cnly trat cortion 
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of memory indicated in Figure hs Any process that 
communicates with the CSP 125 must have its data Space 


located ın that area of memory. 
er General Features of the Prooosed System 


a. Segmentation 

The initial ceciston that had to be made to 
solve the problems stated above was: what type of memory 
management modifications to UNIX were required to provide a 
general and efficient operating system which would suoport 
alignment of a resident process's data space ın a aiven 
region of memory. The segmented memory manaaer desianed by 
Emery (SUNIX) was chosen ‘ee a basis for the intended 
Meadıtıicatıons,. Seamentation had several advantages which 


mone this choice attractive. Process imaaes in UNIX consist 


of several koa can |y independent segments. ASEO UE mort 
managed seoarately, this natural division proviares an 
appealing basis for seamentation. Modai fications to tne 


existing memory management routines to ımolement SUNIY were 
Strarahtforward and relatively simole. 

The segmentation chosen also proved to ve an 
efficient way to hancle dynamic changes in the size of User 
data and stack areas. In UNIX, when the User space  arows 
beyond tne available contıauous memorv space, it 1S 
necessary to reestablish the entire process image ın main 
memory. This 18 accomplished by cooyina the process image 
to a new free area of sufficient size. Since fhere iS no 


hardware facility on the PDP-11/50 for a "block move ın 


io 





memory, this 1S WS" major source of memory management 
overhead. MMe ost or the Copy operation is about 19 
microseconds per wore [4]. This figure is even worse if 
space is not readily available for the larger image and 
other processes have to swapped out to make room. In SUNIX 
the User's data and stack are managea incependently. Growth 
of either area requires reestablishino only that seament in 
memory. Total overhead due to dynamic in-core exoansion is, 


therefore, reduced. 


O. Data Space Alignment 

After deciding on SUNIX as the operating system 
which would best E Bene, OugGooses Of thas tresis, a metros 
of oositionina a precess's data soace at a particular 
location in main memory had to he'tceveloped. Detailed 
analysis of the memorv manaaement routines in both SUNIX and 
UNIX was necessary before oroceedirg. The method chosen, 
and implemented in SSUNIX, was a direct extension of SUNIX. 
No modification to the segmentation scheme was necessary, 
and only minor modifications to the other memory management 
routines were required. The aenera! aporoach taken Was to 
implement the necessary changes by aching Several system 
routines to acquire, e and release a snared memory 
asset. System calls were imolemented to perform these 
functions for processes requiring shared memory. 

Proviaging system Orotection was a secondary gos! 
in the desian of a memory manager for SSUNIX. Tha concent 


Of system protection implies that inadvertent destruction of 
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vital process information, particularly the process control 
Nor mation used by the operating sytem, will not occur. 
Address range limitations of the peripheral processors 
prevent their manipulation of data in memory locations 
outside of the sharea region. SSUNIX allows only the data 
space of processes communicating with these devices in this 
region. The combination of these two features provided the 


Svstem orotection desired. 
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NA EUA “OPERATING SYSTEM 


Thus far in this thesis, the UNIX operating system has 
been aiscussed in general terms. This chaoter provides a 
more detailed discussion of the conceots of system 
operation. Conceots in the design of the memory managers in 
UNIX, SUNIX and SSUNIX are also presented. This cnapter 
provides the backaround necessary for SuUmagerstancdine “tne 


modifications made to UNIX to implement SUNIX ard SSUNIX. 


epee ONCEPTS OF OPERATION 


UNIX (71 is a terminal oriented, time-sharing operating 
system developed at Bell Laboratories- = for the.. Digital 
Seaumoment Corporation (DEC) PDP=-11 family of minicomouters. 
oo? the source code for UNIX is written in "C" (921, a 
high level systems imolementation lanauage. The remainder 


10 


of the source is written in "as” (10], a Bell Laboratories 
variant of PDP-11 assembly languace. 

MIES =Ssk ino. in UNIX is performed om a basic unit of 
«Ork called the process. A process consists of system 


control information» executaole INRSstruct j1ons, na 2 data, 


Maem. the operatina system is "bootstrapoed” into memory at 


system initiation time, wc anderafrts: its first two 
processes. Process Q ES the master control crocess (the 
scneguler "loor") „nich executes until UNIX terminates, 





Process 1 initializes the operating environment for other 
processes in such a manner that all subsequent processes are 
its descendents. All other processes are executions of 
program files from the UNIX file system. 

Descendents of a process are created by execution of the 
"fork" system call. This svstem call replicates the calling 
Bercase, creating a new (child) process that has a uniaue 
process number. The original orocess, called the parent, 
ean Continue execution or temoorarily susoend itself until 
the cnild terminates. A child orocess mav either continue 


execution of the same oroaram or invoke a new program into 


e n 


execution. New processes are invoked by "exec", a system 
call that "overlays" the callina orocess with an executable 
file from the file system. Child processes may also spawn 
children of their own. When any child completes execution, 
iemeerercminmates by means of tne "exit" system call. “Exit” 
notifies the parent of the child's termination. 

The primary role cf Process 1 is to create a child 
process for each of the terminals in the systen. These 


processes open their assianed terminals, oromot for a user 


to hee Fin, and then await a reoly. Unce a user nas logged 


In, the child invokes a new croaram (using "exec") called 
the Shell. The function ot thre Sbhell is “to ioterorent 
commands from the termina) and create eh oren which 


accomplish the desired operation. “hen the user loas off, 
the Shell process for his terminal is terminatec. Process 
l, NAICH 1s then notified of that cnilda's demise, creates 


emotner chila for the terminal. The new child reopens tne 
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ermina! and oromets for another 1og in. 

From the User's pcint of view, the most important role 
ore UNIX is to provide a file system pE There are 
Basically three kinds of files suoported by the system: 
ordinary disk files, directories, and special files. 
Ordinary files contain whatever information the User places 
on E Source programs, object modules aenerated ody 
comoilers or assemblers, and pure text are examples of 
ordinary files. Directories provide a maopina of ordinary 
file names to the files themselves», thereby inducing a 
structure on the file system. All files in the system may 
Bemenocated by tracing a path from the "root" directorv to 
the desired file. User interface to each inout/ouput (1/0) 
device supported by the system is throuch a device-specific 
special file. with this scheme, 1/0 devices can be treated 


as ordinary files. 


B. MEMORY MANAGER DESIGN 


The UNIX memory manager iS, in concept, a relocatable 
partitioned memory manaaer with swacpina and Limited 
segmentation. While the orocessor is executing in behalf of 
a process», tne process image must reside in a contiauous 
Begion in main memory. As already exolained, furia . tne 
execution of other orecesses, a Process may remain in memory 
d ess scheduling of a hiaqher priority orocess ‘forces it O 
be swapped out (cooied) to the swao device. UNIX processes 


mie brogical ly Gividec into three parts: eha ly ee lak, tne 
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User data space, and the User processor stack. [If a process 
requires use of shared text, its data space contains only 
data. Shared text 1S managed separately. 

The UVECTOR contains all process status information 
required bv UNIX while the process is resident in core. 
Other orocess status information, which must remain 
addressable throuahout the life of the process, 1s contained 
imma system contro} block called a PROC. In tne case of 
shared text, the PROC contains a pointer to vet another 
stem comtrol block called a TEXT. This block contains all 
information necessary to control the sharing of a text 
segment by one ar more processes. Shared text, if recuired, 
is established in memory  indepenaently of the processes 
which are sharing it. If a process shares text, "exec" 
checks to see if a copy of the text segment is already 
available in the system. If it is not, a copy is created. 

User address space of a text-sharina process may De 
created with separate instruction space (l-space) ana aata 
space (D-space), or with combined I[-space and U-svace. User 
adaress space for nor-sharina processes is established with 


combined instruction and data soaces. It the I-soace and 


D-space ot a orocess are combined, there 1S no 
aifferentiation between instructions and data. Tae) te 
mee 171 of an executable file is used hv "exec" to 
Set aolisn a separation flag in the UVECTOR. TRIS flaa is 


used to control the rethod by which the address soace for a 
text sharing orocess 1s estabdlisned. The srared text 


segment cf a process with seoarate address spaces is 
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addressed beginning at User l-scace address 0? data is 
addressed beginning at User Desoace address 0. It 3 Drocess 
with combined address spaces has shared text, the text 
segment is addressable beginning at address ù in both I- 
space and De-snace. Its data is addressed in born I[-space 
and O-space, beainning at the first 4K word boundary above 
the shared text segment. For processes without shared text, 
the text is addressed beginning at address 0 in the combined 
I=sopace and Uesoacer and its data 1s addressed Feainning at 
the fst word boundary above the text. The User's 
processor stack is adcressed extending downwara from Ene 
Best address in D=space or combined I-space and D-space. 
POP-11/50 aaae address registers (PARS) and page 


descriptor registers (PDRs) are loaded when a process image 


n brought NEO memory or its address soace 1s 
reestaolished. PARs are used by the MMU to trans late 
virtual adaresses to envsical memory addresses. PDRs are 


used to descrivde a set of attributes about a resident 
process's pages. A page in UNIX can be thought of as a 
Semertcion of a process imace which can be up to UK words in 
lenath. Access control soecified in the PURs is read only 
for shared text pages and read-write for all other oaaes. 
User data soace may vary dynamically if required aurina 


execution of a orocess. Noms il creak", 1s provided 


im UNIX to alter the size of the data area. ROCS Ciona d yy 
the size of a process image may be increase oy dynamic 
Browth of the User orocessor stack. When this ceccurs, the 


system automatically increases the amount of scace provided 
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hor the process. IO or these. cases; UNIX ~ must 
reestablishn the entire process image in mair memory. As 
mentioned coreviously, one of the primary benefits of 
segmentation is indicated here. SUNIX and SSUNIX reauire 


that only the segment whicn changes size be reestaolisned. 


l. Segmentation 

Segmentation of shared text 15 already wel] 
supported in UNIX. SUNIX and SSUNIX further diviae process 
images into the three natural segments menticned before: 
UVECTOR, data space (including non-shared text), ana User 
stack. Allocation of memory space for a process is 
accomolished by separately establishina each segment in a 
free area large enough for it. Comeroucus “ahieceat ion. <n 
memory is possible, but not required. Swao space for a 
Smocess is stil! allocated in a contiauous oartition on the 
system's swap device. However, Pr to the Separation of 
segments in main memory, up to three cooy operations” are 
required each time a process 1S Swapoed to or from the swao 
device. In UNIX, only one copy operation is reacuired. 
Thus, there iS an increase in svstem overheao with seamented 
memory management. There is, however, a comoensatina 
advantage to segmentation: a reduction of overheaa (Seament 
copying) results from independent management ot data and 
stacx segments if dynamic growth of ore of these searerts is 


required. 
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es. Allocation of Memorv Space 

The basic quantum of memory space in JINIX is a 
64d-byte area called a block. This is the smallest cuantum 
Wecorteo by the PDP-11/50 MMU. Memory space for each 
process is assigned from a free memory mac maintained by tne 
operating system. This map, which is establisheo at system 
Ma tion time based on physical memory configuration, 
contains the base address and size (in blocks) of each 
unallocated area of User memory space. Addresses 19 tne man 
are increasina in order and represent the onvsical block 
number of the free area to which they refer. Tne operatina 
system is established beginning at ohysical address 0. User 
memory space beains at the first block boundarv above tne 
system code. 

Maintenance of the free memory mac is performed ody 
the mnemory management orimitives “malloc” and "“mfree", 
These system routines are also generalized to  certorm 
maintenance of all other system free maps; for examole, tne 
swap mac, and the shared memory maps (described later) in 
SSUNIX. Meta tran of malloc" is to logate an arsa of 
emen Size in the Given mao, update the map to reflect tne 
allocation of the area, and then return the physical block 
Bumber of the allocated area to the calling routine. The 
algorithm used in "malloc" is fiesta tits That is, the 
free map is searched seauentially, beainnina witn tre first 
entry, Sa an area Of Sufficient size to satisfy tne 
request 1S found. If the requested space is not available, 


a zero value is returned to the caller. Thee Same tO manor 
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"mfree" is to free the area specified by the callina 
NOutine. The reaion soecified is sorted back into the free 
map and combined on ore or hoth ends if possible. In UNIX, 
processes are allocated space based on the sıze of the 
entire process image. In SUNIX and SSUNIX, each seament of 
a orocess is allocated memory space separately tased on the 


segment size. 


3. Multiported Memory 

Regions of multiported memory are often cesirable to 
supoort peripheral devices which have uniaue DMA 
requirements. Examoles are devices which nave hardware 
address rance limitations or require real-time memory 
Bess, Specific aoplications of multioorted merory in the 
SoMa | Processing and Disolay Laboratory have already been 
discussed. 

To support multiported merory, the operating svstem 
must be able to align a orocess or process segrent ın tne 
multiported memory reaion. UNTX does not rave cas 
Gapaotlity. As exolained in the previous section, “malloc” 
assigns memory space from the User free map cased on a 
Ms tft" algorithm: a as. algoritam; alignment 
within a specified region of memory would re purely 
coincidental. Furthermore, since OMA oy a pericneral device 
to UVECTOR or stack addresses violates system security, only 
the data segment is claced in the multipnarted reoınn. his 
implies that seamentation ıs a desirable memory management 


scneme in a system configured with multiported memory. For 
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this reason, SUNIX was chosen as the basis for development 
of multiported memory system support. Althouah there was no 
provision for data seament alignment in SUNIX, the method of 
process seamentation directly suoported the desian effort 
undertaken by this autnor. 

In order tO investigate mult 1 Oorted memory 
aoplications RETOS a shared-seqmented memorv manaaer 
(SSUNIX) was desianea and implemented. SSUNIX oreviagea tne 
ability to alian a callina process's data segment in a 
shared memory region, and to ensure system protection by 
clearing all other processes from that region. Free memory 
maps were established and maintained for each shared core 
area. Processes recuested the shared memory asset vijia a 
system call ("getsnr"). A system routine was designed which 
checked the User free memory map to determine if the 
requested region was free. If the area was free, it was 
removed from the User free memorv map and the cata Space of 
the calling User process was moved to the sharea reaion. 
The "malloc" svstem call was used to allocate scace for the 
gata segment in the requested shared reaton. Kr the area 
was in use DY another memory-sharing process, the cata 
segment of the calline process was simply allocated in  tne 
shared memory map and then moved to tre region. Tf the area 
sas in use by other non=memory=sharing orocesses,s these 
processes were Swaoced out of memory until tre area was 
clear. The data seament of the callina User vrocess was 
then allocatea in tne shared memory map ana ravea to the 


Begiıon, 
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In each of the above cases, after a shared memory 
region had been acautred for a memory-sharina process, non- 
memory=-sharina processes were not allocated soace within the 
Baunds of the shared region. Additionally, the callina 
process was locked into memory so It would not be swapped 
out of the area. Another system call ("freesnr") was 
implemented to release a orocess's shared memory asset and 
unlock the orocess imace. This system call updated the 
Shared memory map. If no other mnemory-skaring orocesses 
remained in the reaion, the entire shared memory area was 


returned to the User free map. 
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NDA TECATEONS TO UNIX 


A. GENERAL 


Modifications to tne UNIX overating system to  oroguce 
SUNIX were oerformed ty Emery (4) in mid-1976. Tre approach 
taken in the desian was to make the general Seuc ture wie! 
memory management familiar to those who understood the 
peapeerure of UNIX. This aporoach led to a well-designed 
operating System which readily supperted further 
modifications and  debugalng. However, due to areater 
emphasis on the completion and testing of a cartitioned 
segmented memory manacer fPSUNIX), SUNIX was not inolemented 
at that time. Final imolementation and testing of SUNIX was 
A imary Goal of this thésis project. SSUNIX was to be 3 
ect extension of SUNIX. For this reason, modıficatıons 
to UNIX required to irolement SSUNIX encomoass those made 
meme ouUNITX. 

The changes necessary to imolement orocess segmertation 
with data segment alicnment affected five general areas: 

econ rol Sloéks 

d. Memory Manaaerent 

Se swam <obace Allocation 

4. Shared Memory Allocation 


S Supoort Proarams 
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Each of these areas is discussed in a Subseauent section of 
this chapter. The apcendices to this thesis orovide further 
mecumenmtation. Information om contro! block modifications 
is found in Aopendix 4. Memory management and shared core 


allocation modifications are described in Aopendix B. 


See CONTROL BLOCKS 


UX control blocks. are data structures used by the 
operating system to maintain information vital ¡to system 
Amro. The only control block modification required to 
support process segmentation was the PROC. A list 
containina a PROC for each active process is maintained by 
the system. In UNIX, a PROC contains the block address of 
the UVECTOR and the size of the process image (which goes 
eeu 1nciude shared text). Dm SUM CS NO Soul xa ta: PRUE 
contains the block address of each of the process segments 
and the sizes of the cata and stack segments. 

Several new control blocks were added to imolement data 
segment alignment within a shared Core area. SHVYEM defines 
the upper and lower bounds of each shared memory reaion. 
Svstem shared core configuration changes reauire mocifyina 
the entries in this structure. SHMEM 35 usec at system 
initiation time to initialize two other shared memory 
eomtcrotl blocks. see contains -informatic -about a 
particular shared-memory asset., The high and low bounds of 
the region, a flaa incicating whether or not tne region 1s 


in use by another memory-sharina process, and arotner rtlaa 


55 





weed by “malloc” “are maintained here. A SHRMAP is a 
structure which contains a free memory map for each of the 
shared regions. The maos in SHRMAP were configurea exactly 
like the other system free maps so they could te maintained 


eye 'malloc™ and "mfree". 


Co MEMORY MANAGEMENT MODIFICATIONS 


Adaptina the existing UNIX memory management routines to 
perform orocess seaqmentation was a Straigntforwarc problem: 
in each routine that cealt witn a process imaae, the orncess 
imaae was managed as three indeoendent seqments instead of a 
single entity. although sinply stated; solving this problem 
ean rec many hours of familiarization with existing UNIX 
concepts» and modifying several hundred lines of Source 
code. Details of these modifications are not included here, 
but are contained in Apoendix B. Copies of system source 
dode cannot oe included in this thesis due to UNIX none 
disclosure agreements. However, authorizea UNIX User's mav 
acquire machine-readable cooies by contacting tne Nava! 


megqmearacuate Schoo!. 


SIN AP SPACE 4LLOCATION MODIFICATIONS 


Swap Space 1s allocated te a orocess „hen y + must be 
swapped out of memory, and freed wnen the process returns to 
memory. A mao of free soace on the system's swar Jevice 1s 

n 


maintained OY a Loc ” and "nfree". The svstem routine 


"“Swao”" is used to trarsfer data oetween memory and tne SWAD 
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device. SUN O UNAS processes consist of three 
segments that are incependent])y established 1n main memory. 
Moving a process image to the swap device requires a "swap" 
operation for each segment. Also, when shared text must ve 
established, an additional Swap. Operation is involved. 
Actual space on the swao device is allocated in a contiquous 
poe k. The Gdisk address of the process is the address of 
the UVEETORZ Data Ma and stack sarer located 
immediately followine the UVECTAR. Shared text is 
separately established, and retains it swap space until 


there are mo longer any live orocesses which reauire it. 


Es SHARED MEMORY ALLOCATION MODIFICATIONS 


The basic ideas underlying the design of ar Shared- 
segmentega memory manacer for UNIX (SSUNIX) were presented in 
Chapter III. Actual aqesian work was started after SUNIX was 
implemented and had demonstrated satisfactory performance. 
The approach taken in the develooment of SSUNIX was to aad 
several system level routines to perform tne shared memory 
management functions, ana thus modify existing SUNIX code as 
little as possible. Three new system routines were adaea: 
"ckmao", to check the User free memory map; "shalloc", to 
allocate a orocess's data segment to a alven snared core 
region; and "snfree", to free a process's shared core asset. 
Svstem calls for Il!iser proaram interface with "shalloc" and 
"snfree" were also implemented. Brom a User S$ “procram, 


Betshr" acauires a shared care asset, ana "freeshr" 
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releases it. A brief summary of each new routine and tne 
other modifications made to SUNIX is provided in tne 
following paragraphs. Detailed information can be found in 
Appendix B. 

The new procedure "ckmao" was the basic orimitive used 
mamesiared core allocation. Its function was twofold: check 
the User free memory rmac to determine if an area between a 
given high and lcw block address was free, and then, if the 
area was free, remove it from the free mao. The gesian of 
this procedure orovided an interestina challenge. Once it 
was determined that the area was free, several boundary 
alianment conditions had to be considered in order to remove 
it from the free memory mao. EneSipreecedure “oshalloc* 
performed the actual allocation amd assianment of a 
processes data seament to the requested shareo core area. 
it also locked the crocess image in memory. The alcorithm 
melts mented was described in the orevious chapter. in order 
to prevent allocaticn of another orocess within the shared 
Somemnmegion durina the shared core acauisition by “shalloc”, 
a slight modification to the memory management primitive 
"malloc" was recuireo. A orccess's shared memorv asset was 
freed oy "shfree". In addition to the system call 
Meeertace, this routine was called from tre "exit" orocedure 
to ensure that a crocess's shared core was released aft 
Bim@cess termination. 

Other modificaticns to SUNIX ineluded: "main", to 
establish shared core regions əra initialize their 


BecDeGtive comtro! blocks; and "sysent”, to provide System 
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emery points for the system calls “Jer snr and "freeshr.. 
mre source code required to build both SUNIX and SSUNIX can 
be found in the directory /usr/sys.sunix on the display 


processor's file system. 


F. SUPPORT PROGRAM MODIFICATIONS 


One supoort proaram modification was reauired for SUNIX 
amo SOUNITX. The Shell command "os" ([11} cisolays certain 
information about active orocess status. It uses the PROC 
mest tO acquire this information for displav at the User's 


terminal. Simee the structure of the”"PROC was moaified to 


support process segmentation, certain variables used Fy "os 
were invalidated., In particular, the address and size of a 
process image in UNTX were described in two variables in tne 
PROC. In SUNIX and SSUNIX, five variables were required: 
UYBETOR address (its size is fixed at .5K words), data 
segment address, data segment size, stack segment address, 
and stack segment size. To retain tne display format used 
by "ps", it was decided that all five of these attributes 
would not be oresented. Since the User is normally 
concerned with only his data segment's aadress and  S128» 
these values were substituted for the existing values in 
n 


DS The revised version of this routine can te found in 


/usr/sys.Sunix on the disolay orocessor's file system. The 


H 8 


object version of os tound in bDi must oe replaced with 


the revised object during SUNIX ana SSUNIX operation. 
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E AA TONE PERFORMANCE 


A. OVERVIEW 


ASS SES emrouacnout this report, completion and testing 
SUNIX was an integral part of this thesis ana a 
prerequisite for the development of SSUNIX. A severe 
problem with the SUNIX memory manager had orevented its 
final implementation. This problem manifested itself in an 
inability to assemble certain proarams. Since the assembler 
is used durna a bass of the "C" compiler, compilations were 
also affected. Several weeks at the outset of this thesis 
project were required to become familiar with, debug and 
test SUNIX. Once familiar with the concects of system 
organization and memory management, tmery's desicn reacily 
Sulemorted the debugging effort at nand. Tne oroblem was 
eventually found and corrected in tne memory management 
routine "exec". Development», imolementation ard testing of 
SSUNIX followed. Performance of SUNIX and SSUNIX was 
evaluated in relation to UNTA. Additionally, tests were 
Somaieted which demonstrated the capability of SSUNIX to 
perform data segment allocation and deallocation of shared 


Sore. 
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oe COMPARISON WITH UNIX 


Ihe method chaoasen to compare performance of UNIX, SUNIX 
and SSUNIX was to use the elaosed execution time of a 
standard stream of processes (benchmarks). A series of 
benchmarks was run to determine relative oerformance under a 
mare ty of operatina conditions. Available User memory was 
the variable used to establish these conditions. Two 
benchmarks were used: a monoproaramming benchmark, BENCHI; 
and 3 multiproaramming benchmark, BENCH2. These benchmarks 
are essentially identical to those used by Emery in his 
testing of PSUNIX. Roth BENCH! and BENCH2 contain the same 
sequence of UNIX commands. These commands are documented in 
Ref. les APPENDIX C contains benchmark Listings. ie 
computer system used for the tests was the multiuser side of 
Baemeranoratory configuration shown in Figure i. A single- 
user environment was established with only the console on- 
line. The purpose of this was to prevent the introduction 
of an added variaole in benchmark performance caue to 
processes aenerated by other Users on the system. ihe swao 
soace and file system used were located on RFOS disk units 
fo)’. 

Table I preserts the results of benchmark tests for 
Bey SUNIX and SSUNTX. Available User memory space was 
varied to evaluate performance over a wide ranae of svstem 
Geant yaurations. mino date was obtained by using the UNIX 
"time" command [11]. Processes run under control of "time" 


are clocked by samolina processor state at the rate of 00 
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Hz. "Real" time reflects tne total elapsed time for the 
process and is reported to the nearest second. "User" time 
is the time spent in the User state (je. executing the 
User's program instructions) and is reported tc the nearest 
tenth of a second. "Sys" time 1s the time spent during tne 
execution of operating system supervisory instructions and 
is reported to the nearest tenth of a second. The 
difference between "real" time and the sum of "user" and 
"sys" times indicates the amount of processor idle time. 
Idle time generally reflects the amount of time spent on 
asynchronous I/90 operations. 

In addition to benchmark testina in a single-user 
configuration», UNI as run. tor a fúll day of multiuser 
proaram development. The system was fullv configureo aaa 
1) and moderate to heavy system utilization was noted. 
System Users were asked to report any orobdlerms to the 
laboratory staff. No system failures occurred and no 
problems were reportec. This test orovideqd an excellent 
Names tion of prober system ooeration as well as the 
transparency of the memory management method to system 


USers. 


SHARED MEMORY ALLOCATION 


Testing of data segment allocation to sharea core was 
performed on the aısolay orocessor. The system was 
confiqured with a single terminal and the system console. 


3w30 space and the file system were maintained on PPOS disk 


40 





units. To demonstrate the verformance of SSUNIX, it was 
necessary Come veto a method, for displaying certain 
relavent system information. Three items were reauired: the 
location of a process's data seaqment in memory, the state of 
the User free memory map, and the state of each of the 
shared memory maps. This data best indicated the shared 
memory allocation/deallocation process. A system call 
("shtest") was developed to display this inforration at the 
display processor's console, Several test orograms which 
moeuded shared core allocation requests ("getshr") and 
shared core deallocation requests ("freeshr") in various 
sequences were develooed. "Shtest" was included in these 
proarams to disolay the required information after each 
shared core ooeraticn. This aporoach proved invaluable in 


the debugging and refinement of SSUNIX, 


DAN AEYSIS OF RESULTS 


The results shown in Table I eae indicate that the 
performance of UNIX, SUNIX and SSUNIX are nearly identical. 
No statistical analysis was performed on these results, but 
earlier work [6] indicates that the sampled data may have a 
Stencard deviation of as much as 8 percent on identical 
benchmarks run severa!) times on the same system. System 
supervisory times ("SYS") under SUNIX ana SSUNIX were found 
to be sliahtly better than UNIX in some cases. This is a 
surorisina result in Jıiant of the more complex memory 


management fümetıon with orocess seamentation. The 
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disadvantage related to increased swaopina overhead did not 
aopear to degrade cverall system performance. A probable 
explanation for this result 1S an offsetting oerformance 
improvement due to independent dynamic growth of aata and 


stack segments. These factors were discussed in Chapter 


ar], SSUNIX's oerformance in a nultiported memory 
environment was validated. The tests oerformed usina 
msatest " indicated Chat shared core allocation and 


deallocation of a orocess'S data was pronerly managed. 
Additionally, since SSUNIX benchmark timing data was so 
Ney identical to that of the other systems, the data 
segment alignment capability had no siantficant effect on 


system performance. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


The primary goal of this thesis, an extension of the 
UNIX memory manager to orovide data segment alianment with 
system protection, was successfully implemented in the form 
of SSUNIX. Perfornance results were encouraging. However, 
before the benefits of this system can be fully realized, 
other related development work in the Sianal Processing and 
Disolay Laboratory is necessary. This chapter provides 
recommendations directed toward the development of a total 
system support oackage for the laboratory's display 
processor. åàlso included is a recommendation for further 


research in the area of segmented memory nanaaerent. 


CONTROLLED MEMOPY ALLOCATION 


Several different operatina systems for the display 
processor have been developed to ocrovigde suoport for special 
peripheral devices. Two of these systems were designed to 
provide process alicnment ima particular area of mewory: 
one for CSP 125 processes, and another for VG processes. 
The existence of a number of different operating systems, 
each with a particular aoolication, causes a sianıficant 
Some vauration control problem in the laboratorve. Since 
SSUNIX was designed with these specific aoplications ın 


mind, Q@ direct imolerentation of this system on tne disp!av 
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Brocessor would simolify the system configuration contro! 


problem. 


BRSZMULTIPROCESSOR INTERFACE 


endi cated im Figure 1, the PDP-11/34 slave processor 
is presently treated as an independent system oerioheral. 
The design work done by Grav [5] has not yet been tested in 
the multiprocessor environment for which 1t was intended. 
Additionally, the hardware interfaces for the 32K word 
shared core area ard the VG disolay device have not oeen 
implemented. The dashed lines in Figure | depict tne 
configuration required to complete the multyjprocessor 
interface. Once this is done, imolementation of the slave 
processor's operating system and integration of SSUNIX into 
the multiprocessor environment could follow. Investigation 
of the communication reauirements and protocol between the 
master crocessor and the slave orocessor is required. Also, 
the inter-orocessor graphics supoort  nackage desianed oy 
Visco [12] must de reviewed to ensure prooer interface with 
the "getshr" and "freesnr" system calls of SSUNIX. Only 
slight modificatton te SSUNIX woulda oe reauired to establish 
this interface. One  sugaestea aporoach is to imolement 
Visco's "rtime" amd "nonrtime" system calls in SSUNIX to 
Sora the functions as "“getshr” and "freeshr". This 
acproach has the advantaae of requiring only simole 
meauri+estions to SSIINIX and no modifications to the grachics 


terface routines. Another cossionility iis madifying the 
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Vector General routines to acauire shared core via "getshr", 


and release it via "freeshr", 


NT VESTIGATION OF SWAPPING POLICIES 


The disadvantage of seamented merory management 
Geauiring a greater number of cony operations for Drocess 
Swapping has been stated oreviously. An interesting topic 
for further investication is the develooment of ar extension 
to SSUNIX (Cor SUNIX) which imolements swappina on a seament 
basis. Modificaticns to SSUNIX fo SUDBOTFL this 
investiaation would involve revision of the process 
scheduling routine "sched", the orocess memory allocation 
routine "eralloc”, the routine for swapping processes out of 
core, "xswap", and the routine for swapping processes into 
core, "orswap". Tt is contended that, althouah the memory 
management function will be sliahtiy more comolex, the 
actual changes reauired to existing routines will not 
degrade system performance. In fact, since swapolng Isa 
significant factor in system overhead, an optimum swanpinga 


policy should enhance overall performance. 
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APPENDIX As CONTROL BLOCK MODIFICATIONS 


Ae DOCUMENTATION FORMAT 


This apoendix 1s intended to be used with a coov of tne 
Source code for UNIX (Version 6), SUNIX and SSUNTX. It 
contains documentation of the modifications made to UNIX 
Goat ro | blocks to implement the two new segmented systems. 
source code for these control blocks in the UNIX form is 
mound in the directory /usr/svs. source code for the 
modified versions can be found in the directory 
/usr/sys.sunix on thesaısoley processor's file system... The 
format of this appendix and some of the documentation 
contained herein are identical roe SBPRENG TX A tof Ret. 4, 
Each control block is gesceribea under an upper case roman 
letter. Tre control block name is followed by the source 
code file in which it 1s found. An overview and a 
description of sianificant data elements is provided for 


@eeenrcontro!] block. 


Dis SHRMAP, share.h 


l. Overview 

SHRMAP is a structure containina NSHARE free -memory 
maps of shared core regions. NSHARE is a tunable parameter, 
SEOS Ound Im "share.n’,;, which soecifies the number of 


shared core areas in the system. DER SsBceSsAaArtFrollklock iS nor 
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founa in UNIX or SUNIX. Each map in SHRMAP is an inteaer 
array containing the physical block number and size of an 
unallocated memory area. The maps are sorted in physical 
Diioaece« number order. Wis cCommigucet ion. 1S identical to 
COREMAP and SWAPMAP, Documentation of malllocrcı in 
APPENDIX B describes the memorv management primitives which 


manipulate the free memory mans. 


Cn Significant Data Elements 


3. int Shmap[SHMAPSIZ] 
This is the soecification for a single shared 
memory map contained in SHRMAP. SHMAPSIZ is a tunable 


parameter defined in "share.h". 


Dl char *m¢size 
This is the size of the free area in 64-bvte 


blocks. 


E. char kmeacdr 
Inis is the Tohysical: block number of rhe 
beginning of the free area in the shared core reqion. [f 


this value iS zero, it marks the end of the map. 


le Overview 
APO RRENCOmMtaIMS Certain control information about a 
mored core reglon. There is one of these control vlocks 


"or each of the NSHARE recions. Snare iS ok defined ın 
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UNIX or SUNIX. 


Ce Significant Data Elements 


ae int basadoar 
ais ios the physical block number of the base of 


the shared core region in memory. 


Di int hiaddr 
Hisis hke physical block number of’ the too of 


the shared core region. 


Coe har nuse f la 
This 18 a flaq which indicates that the shared 
core region is in use by a resident memory-sharing process. 
Further details on its use are orovided in apoendix B under 


mememcocumentation of "shalloc.c". 


Geach armme« ¢ iG 
This is a flaa which indicates that no orocesses 
are to be allocated memory soace within the bounds of tne 
shared region. sus Sa malloel)" 1s Gocumented, «Vn 


PERENDIX B, 


DEP ROC,) proc.h 


l. Uverview 

UU located fOr each active process in tne 
system. The PROC exists for the life of the process. PROCS 
ama lntalñed in an array called "orac" which is NPROC in 


size. Tnis array 1s cermanently resident in main memorv and 
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Ao talns al! Ger process information which cannot be swapped 


out of main memory. 


d. Significant Data Elements 


a. char oeflag 
This is a word of flaas. Bit 0 of this word is 
aber SLOADB flaa. If it is set, the process is resident in 
main menory. Bit I is the SLOCK flag. If it is ser, the 
process is locked in memory and mav not be swaopea out. In 
SSUNIX, thıs bit is set to lock memorv-sharing processes in 
memory. Bit 2 of this word is the SINAP flag. Is 


set, the process is Deing swapped out. 


De int peadar 
This variable is oresent only in UNIX. Ut Tthe 
process is resident in main memory, it is the physical block 
number of the process's UVECTOR. If the orocess is smapoed 
out, iit is the swap device block number of the swapped 


Image, 


Es int pesize 
This varıaple 18 oresent only in UNIX. it iS 


the size of the process's swappable imace in 64enyte blocks. 


o mt petextp 
Ihis is a pointer to the porocess's TEXT. E 


value 18 zero, tħe orecess does not have snared text. 
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e. int pecador 
This variable is present only in- SUNIX aed 
SSUNIX,. It is the main memory prysical block number of the 


process's UVECTOR while the process is in memory. 


> Iintamegader 
This variable is oresent only im SUNIx and 
SSUNIX. It is the swap device block number of the orocess's 


swap space. If it is zero, the process has no Swap Space. 


ae int pedsize 
This variable IS present only VAC SUNIX and 
SSUNIX. It is the size of the process's data segment in 


eer=byte blocks. 


Bes int pessıze 
This variable IS present only ın SUNTX and 
SSUNIX. it is the size of the process's stack in 64-bvyte 


blocks. 


OU VECTOR, user.n 


l. Overview 

[Rewestruietuge “User” 1s referñed to as the UVECTOR. 
Une of these structures is part of each swapoable orocess 
1mage. The UVECTOR contains all orocess data that Sot 
needed when the process is not in control of the processor. 
Men ithe process is ir control of the processor, its UVECTOUR 
resides at a fixed location In the operatina system aata 


soace. 
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PAS On iticant Data Elements 


de int veuisalle) 


In UNIX this arrav contains 


displacements 


the 64-byte hlock 


from the start of the reaion of the process's 


Gata and stack caaes. ae ouUNILA ama SoUNT*® “this array 15 not 
used. 
Da int ueurisallo) 

This aray contains the porototvpes ot tne 
process's user I-spaco and Despace page descriptor 
registers. 

Eis int uetsize 

This is the size of tke orocess's shared text 

segment in ó6d4-byte blocks. 
Er int utasize 

This is the size af the process's data seament 

MO >=byte blocks. 
ee int uessize 
This is the size of the process's Stack secment 


in b6b4ebyte blocks. 
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I. APPENDIX 83: MEMORY MANAGEMENT MODIFICATIONS 


Bee DOCUMENTATION FORMAT 


As with APPENDIX A, this apoendix is intended to be used 
mor. a coby of thá source code for UNIX, SUNIX and SSUNIX, 
Meme omtains documentation of the modifications to UNIX 
memory management functions which were resauıred to erogqguce 
the two segmented systems. The format used here, and some 
ami the documentation, is identical to APPENDIX B of Ref. 4. 
UNIX source code is divided into several fires: cont ain ina 
memaced blocks of code. The functions documented in this 
aopendix are arouoed under an upper case roman letter and 
Menane of the file in which they aré found. Each function 
in each file is labeled with an arabic number. The 
documentation af each Function aSa divided. Irto four 
suosections: oarameters, UNETE de Ss CTD RN + returned 
values, and error cencitions. The files containing the UNIX 
functions are founa in the directory /usr/sys/ken. Tne 
eS containing the modified versions of the functions for 
SUNIX and SUNIX are found in the directory 
/usr/sys.sunix/ken on the display processor file system. in 
menor Girectory, those files which contain modifications 


een tie to SSUNIX are oretixed with tme letters "sh", 
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Bs maine 
o maın() 


a3 Parameters 


This fúnction has no Oarameters. 


D. Functional Descriotion 

This 18 the operating system initiation 
function. Physical memory configuration is determined, User 
memory space is cleared, and all system free maps are 
Paci alized. Process 0 and Process 1 are created. In 
SSUNIX, the spec tyeastıon array Fort shared core 
Tan guraton, “shmem", is found tn the file “main.c”. This 
function Merle: onmem oO anitialize the, SFRMAPS and 
SHARES described in APPENDIX A. Shared core configuration 
changes are managed by modifyina the entries in "snmem", 
MESA completion of initiation tasks, the process Schedulina 
moutime, “sched, is called. "Sched" then runs until the 


operating system crashes or 18 otherwise terminated. 


Ci Returned Values 


This function does not return. 


or Error Concitions 
Aerop OGGUrPS if the system clock cannot be 


ecto] ished. 
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2% estabur(nt,nd,ns,seo) 


are Parameters 
The first three parameters are tne s1zes of the 


current process's shared text, data and stack segments in 


64=-=byte olocxs. The last parameter is 3 separation flaa 
that 1s set if the process has solit instruction ano data 
spaces. The current process's UVECTOR is an imolied 


parameter. 


Cuan tional Pescriotion 

Innis function first checks the validity of its 
arguments. It loads the orototvpes of the memory management 
page descriptor registers into the array uteuisdl) found. Min 
men current UVECTOR. In UNIX it also loads page start 
disolacements measurec in blocks from the beginning of rhe 
Bon or text into the array utuisal] found in the current 
UVECTOR. The array utuisall is not loaded in SUNIX and 
SSUNIX. Its values are are not required since the values of 
the parameters are placed in the variables uetsize, utedsize, 
utssize, and utseo in the current UVECTOR. In all versions, 
"surea" is called to load the actual memory management 


registers. 


Cx Returned Values 
If the carameters are invalidy minus one iS 


returned; otherwise, a zero 18 returned. 





d; Error ConGitions 
The minus one return tndicates an error to the 


caller. 


Bee GkKSIzcel(At,nd,ns,sep) 


3. Parameters 
The parameters are the same as OT 


"estabur(nt,ndsns-seo)" described above. 


Ds Functional Descrıotion 
ins function is present only in SUNIX and 


SOUNIX. It checks itS oarameters to see if they are valid. 


Gr Returned Values 
If the parameters are invalid, a minus one ES 


returned. Otherwise, a zero 18 returned. 


ds Error Conditions 
A minus one return indicates an error to tne 


Caller. 


ER Ball loc.c 


l.. malloe(mp,size) 


a Parameters 
The parameters are a oointer to a free memory 
fee Fray and the size in oloexs of the region to be 


allocated from the mac. 
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bee EuUMetional Descriotion 

This function allocates space in main memory and 
on the Swap device. If User free memory space is to be 
erelocated, the first Earameter must point to COREMAP, and 
the size must be specified in 64-byte blocks. If swao space 
is to be allocated, the first parameter must point to 
SWAPMAP, and the size is specified in 256-word sectors. If 
shared core is to be allocated, the first parameter must 
point to a SHRMAP, and the size e scecifiea in 6d-povte 
blocks. SUIS YA Ens function checks the global 
flag, omar. Co 4 if COREMAP is specified. If shar ion Es 
set, the function must tnen check the "ckfla" in each SHARE 
before allocatina space in COREMAP, TE emt Loe) S: Se ty sa 
free area which incluces anv oart of that particular shared 


region will not be allocated. 


Cie Returned Values 
If allocation 1s successful, this funetion 
returns the physical block number Of the base or tne 


allocated area. Zero 18 returneo if space 18 unavailable. 


de Error Concitions 
Á zeno returned value indicates allocation 


failure to the caller. 


Cs mfreefmo,$size,aa) 
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De Parameters 
The first two parameters are the sare as those 
for "malloc" described above. The third parameter ıs 3 


physical block number of an area of main memory or Swap 


space. 
Da Functional Nescriotion 
This function frees the soecifieaq area in che 
sBacı fiedg free map. If the first parameter ooints to 
COREMAP, the area is freed in the User free memory map. er 


the first parameter points to SWAPMAP, tne space is freed in 
the free mano of the swan device. ia sSUNTX “only, if tne 
first parameter points to a SHRMAP, the area is freed in the 
Mao? that particular shared core region. Sizes are in 
b6bl-byte blocks if CCREMAP or a SHRMAP is specified, anda in 


¿5b-= word sectors if SWAPMAP is specified. 


c. Returned Values 
The value returned by E function is not 


checked. 


de Error Concitions 


MS fonction Nas mo arror conditions, 
iwc <mao(rla,rha) 


De Parameters 
The parameters are the low adaress and high 
address in ohvyvsical block numbers of a realon of main memory 


soace. COREMAP is an implied parameter. 
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San une tonal Desceriıat ion 

[aVsetUmet pom 1s Present in SSUNIX only. It 
checks COREMAP to determine if the soecified region of main 
memory is free. If the area is freer, it is removed from 
COREMAP and: the map is rebuilt to reflect the removal. In 
order to rebuild the mao, several boundary alignment 
conditions are checked. The position of the free area 
boundaries in relatior to the boundaries soecified in the 
Be merers determines the algorithm used to sort and rebuild 
weno. This functicn is used in conjunction with the 


daneg core allocation function, "shalloc", descriced below. 


Es Returned Values 
If the specified area is free and was reroved 
from COREMAP, a one iS returned. If anv bart of the area is 


in use, a zero is returned. 


ds Error Conditions 


Mis function mas no error Conditions. 


d. shallocíscname) 


a. Parameters 
The oarameter is an integer value wnich 
soecifies a particular shared core region. The PROCS and 
TEXTs of all processes, the current process's UVECTUR, the 


SHARES, amd the SHRMAPs are all imolied parameters. 
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ANS n ona l Descr iotion 

THIS function is oresent only in SSUNIX. it 
performs the shared core allocation process by acauirina the 
region, reservina it for memory=sharing orocesses, and 
positioning the caller's data segment in it. The function 
rst checks the validity of its input argument., The 
Mextig’ for the specified region and the global "sharflg" 
are set to orevent allocation of space within the region 
durina the acquisiticn process. fo ensure that the calling 
process is not within the bounds of the shared core area 
that it is tryina to acquire, it is swapped out of memory 
Mina "ceswae". Since “malloc” wi)! not allocate space 
within the reaion, when the process returns to memory it 
Ninot interfere with its Own acauısition process. The 
wmesce tia" of the shareco core area is checked to determine if 
the area has been previously acquired and reserved for 
sharing. If the area has been reserved, the caller's data 
segment is allocated in the SHRMAP and tnen copied to the 
allocated space. Lf tse areas not reserved, “ckran” is 
Cited to determine if it is free. If it is not free, the 
PROCS are scanned to find processes with seaments in the 
area. Interferina processes are Swapoed out of memory until 
the region is free. "Ckmap" oerforms tke actual reservation 
process by removing the region from COREMAP, The caller's 
Siete segment is then allocated in the SHRMAP 3nd cooied to 
the allocated scace. In any case, after the orocess's data 
segment has been copied to the region, the process imace is 


locked in main memory by seftina the SLOCK flag in the PROC. 
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ce Returned Values 
If the shared core” allocation process is 
successful, the physical block number of the base of the 
caller's data segment is returned. If unsuccessful, a minus 


one 1s returned. 


Gite Ee Grore Comet coms 
The minus one return indicates an error to tne 
ealler. This value can result from one Ot two error 
conditions: improoer inout parameter, or failure to allocate 


the process's data seament to the shared core region. 


54 shfreelo) 


Qe Parameters 
The parameter SIA Dor nter to. the calling 
process's PROC. The SHARES and SHRMAPs are imolied 


parameters. 


Ne tiona) Meseri potion 

This function is oresent only in SSUNIX. It is 
used to free the caller's shared core asset. It first 
checks to see if the caller is a memory-sharinmg process. If 
Sos, that process's data segment is deallocated in the SHRMAP 
Beene region that it occupies. If there are no other 
memory=-sharina processes remaining in the area» it is freed 
in COREMAP and the caller's imaae is unlockec. If any 
memory=-sharina processes remain, the caller's ıimace js 
unlocked and swapoed cut of memorv. In this case, the space 


occupied Dy the data seaqment 18 not freed in COREMAP since 


Sn 





the area must remain reserved. 


Cr Returned Values 


The values returned by hIS function are not 


checked. 


da Error Concitirons 


thas tfuMmction has no error conditions. 


tee sS19.C 


Mm corel) 


de Parameters 


The current process's UVECTOR, PROC, TEXT Tand 


address space are implieg parameters. 


De UnC onal MVescriotión 

This function creates a memory imace of the 
current process's UVECTOR, data, ana stacx. In UNTX this 
function uses "estabur" to redefine the process's virtual 
address space ana make the data and stack contiguous. [t 
then writes the data and stack in one outout operation. In 
SUNIX and SSUNIX this is imoossible because the data and 
Saa may not be chysically contiguous. Two output 
operations are required? one for the data and one for the 
stack. Leen error Occurs during an -outsur operation; an 
Ma Cation is left im utuerror in the UVECTOR of the current 


process. 
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Es Returned Values 
This function returns zero if successful and one 


Mar OuUtout Error occurs. 


Gis Error Concitions 


The one return indicates an error to the caller. 


Ce grow(sp) 


ae Parameters 
The parameter is the value of the current 
process's User stack cointer. The current process's UVECTOR 


and PROC are imolied carameters. 


De Functional» Vescriotion 
This function is called asynchronously when the 
current process's stack attemots to expand byond the space 
allocated for it. his function calculates the number of 


pblocks that the stack must be ıncreased, valıdates the new 


stack size, and acquires the memory that is needed. In 
UNIX, "expand" is cCalleg to establish- the new, larger 
address space for the entire process image. Im- SUNIX- and 


SSUNIX, this functien attempts to acquire the needed space 
by in-=core excansiom cf the stack segment. If unsuccessful, 
it calls "ceswao" to acauire the soace bv swapping. If 
successful, it copies the old stack to the new space and 
frees the old memory. In all versions the newly acaquired 
scace is cleared and "estabur" is called to reload the 


memory manaaement registers. 





Ge Returned Values 
This function returns a zero 1 f it is 


unsuccessful and a one if it 1s successful. 


a. Errertoameı tions 


Ameto return indicates an error to the caller. 


mae S!O.c 
Le schea() 


Qe Parameters 


Ihe PROCS and Texts. of all orocesses are im6lied 


parameters. 


Deen Umer Tong! Oescriot ion 
This function searches for Swapoed out processes 
that "deserve" to ke returned to memory. Ít selects the 
most "deserving" orocess; acauires space for it by swaopina 
out other processes if necessary; and returns it to main 
memory. In SUNTX and SSUNIX two new functions are used: 


werailoc"™ to acauire main memory for the process, and 


MOS Wap” to Swad it in. 


ee Returned Values 
Thais MUNI ados mat return. It ys the basic 
mececuction loop for Process ID. It goes to sleep ana is 


reawakened about once per second by the clock function. 
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a Eeron Londitions 
TORNA SS Hao inout or output error occurs, 
the message “swap errcr”™ will be sent to the console and the 
system will crash. In SUNIX and SSUNIX, the swap operations 


occur in "prswac" so ro error messaoes are aenerated here. 


2, neworoc(nrp) 


de Parameters 
The parameter is a pointer to a -PROC to oe 


estaolished fot a child process, The current process's 


UVECTOR, PROC, and TEXT are implied parameters. 


Ds Functional Description 

This function creates an exact dunlicate of the 
Current process as a child of the current process. It first 
maxes the aoprocriate entries in the child and parent PROCs 
and in the TEXT if ore exists. It then attempts to acauire 
memory for the child process. If it is successful, it 
simply copies the oarent's image to the new memory. be: 
MENS, it Swaps out a copy of the parent to be returned to 


memory as la child.: In SUNIX and SSUNIX, a new function, 


Base", is used to attemot to acauire memorv For the 


ANO. 
Es Raturned Values 
Laie tymecıon returns zero to tre parent 
Process. The return to rhe child dees not come from this 
function, but from the schedulina Fünetıon SAA G Tne 


nia can identify itself as the child because "swten" 
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returns a one to it. This is one of the most important and 


subtle ohenonena tn UNIX. 


d. Erron Conc toms 
If the PROC pointed to by the parameter is 


already allocated te an active process, the message "no 
procs” wil) be sent te the console and the system will 


crash. 


5% expand(newsize), expand({newr,news) 


Qa. Parameters 
Io UNIX fhis function iS Called with a sinale 
argument, the new reaion size. In SUNIX and SSUNITX, this 
function is called with a pair of arguments: the new data 
size and the new stack size. The current process's PROC and 


UVECTOR are imolied parameters. 


bee Swiacttomal Descriotion 

In UNTX, this function is called whenever the 
size of the current process's memory image chanaes. It puts 
the new Size in p*size in the current PROC. If the new size 
is smaller, it sımply frees the unwanted memory., If the new 
size is laraer, it attempts to acauire the rew Space for tne 
process. If it succeeds, it cooies the process image to tne 
new area. If it fails, it causes the process to te Swapoed 
Out with the new sizes noted in the PROC. hen it returns 
to memory, it will return at the new size. If the process 
IS swapped out, this function calls "swten" to rescneoule 


the process immediately. na ans SSUNIX, it puts tne 
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two new Sizes in pedsize and pessize in the PROC. LAN eee 


the FUNCTION calls “xswao" to perform the Swapping 
operations In SUNIX and SSUNIX, the new funetion "ceswap" 
WS used. In UNIX, "sureg" 18 called to load the memory 


management reaisters. In SUNIX ang SSUNIX this is not 


necessary. 


ce Returned Values 
The return values of this function are not 
checked. The caller has no way of knowing if the orocess 
was increased in size Oy direct expansion or by  Swapo1lng. 
In UNIX, if the process is swapoed out, this function aoes 
MO return to its caller. The return comes” from a 
subseauent call to "swtch" after the orocess has returned to 


memory. 


Clie Error Concitions 


This fumetion has NO rror conditions- 


4. ceswao(ods,oss) 


as Parameters 
The parameters are the current orocess's gata 


and stack segment sizes in 64r0vte hlocks. 


UNE EOS Des or Totoro 
This function is oresent only in SUNIX and 
SSUNIX. It Ss called to perform core exoansion swapoing. 
meme a! |S xSwap to de the actual] swaogina and then calls 


"swtch" to reschedule the process irmeciately. 
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Co Returned Values 
ihis fünctioóon does mot return to the caller. 
The return comes from a subseauent call to "swtcn" after the 


process has returned to memorv. 


d: Error Concitions 


Ihis function has mo error conditions. 


Br eys!.c 


le exec() 


a. Parameters 
Me current process. s UVECTOR, PROC: and TEXT 
are implied parameters. Because this function is a system 
eer, the array utuarc{) in the UVECTQR contains additional 


arguments. See Ref, Il. 


So Foment Oona] Descriotion 

jes system call is Used by the current Process 
to invoke a new proaram, it coo1es any proaram arguments to 
a buffer, unlinks from the old TEXT, frees its old main 
memory space, establishes a new TEXT if the new proaram has 
Shared text, acquires memorv space for the new data and 
stack segments, clears the reaqion acquired, reads in the new 
program's data, copies the arauments to the new stack, and 
changes the memory tranaaqement registers to reflect tne new 
address soace. In UNIX, “expand” is called to free the old 
memory space; in SUNIX and SSUNIX, a new function, "orfree", 


is usea. Poe xXoe 'eStabur: ıs used "to validate the new 
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memory reauirements; in SUNIX and SSUNIX, the new function 
"eksize" is used. In SUNIX and SSUMIX, only the 
uninitialized portion of the data segment is cleared before 


the copy operation. 


Cu Returned Values 
This system call returns to the caller only ef 
it encounters an error. rt No error oceurs,sttr Feturns.to 


Wien tirst instruction of the new orogram. 


chs Error Concitions 
This function returrs an error to the caller iT? 


the memory reauirements of the new orogram are invalid. 


ee. exit() 


ae Parameters 
Thezeurrert orocess's UVECTOR, PROC, and TEXT 


are implied parameters. 


DO. Functional Description 

This function is the system call  useg to 
terminate tne callirg cerocess. It: cetlears ali signals; 
closes any open files, unlinks from the current TeXT, 
acquires a block or the swap device, copies the first 256 
bytes of the UVECTOR to the block», ana frees main memory 
soace held by the process. In SUNIX and SSUNIX, tne old 
memory area 1s freed by the new function "prfree". The new 
function “swfree” is used to free any swan space. In SSUNIX 


ally tzazearocess has the SLOCK bit set in its PROC, tne 





Moc ton tresitns called to free any shared core assets 


that the process has been allccated. 


Es Returned Values 
This system cal] does not return to its caller. 
The next function invoked for this process is "wait", which 


completes the cleanup. 


Ge Error Conditions 


This system call has no error conditions. 


3. sbreak() 


ae Parameters 
Ihe current -process's UVECTOR ana PROC are 
implied parameters. Pecause this function is a system call, 
an aditional araqument, the virtual address of the new end of 


the data, is found in the array utuaral) in the UVECTOR. 


BR umetional Deseription 

Mais function is the system call’ used to change 
mpemesize of the callina orocess‘s data area. It calculates 
the new data size desired bv the process and checks tne 
validity of the process's new total memory reauirements. In 
UNIX, “expand” is usec to establish the new region. Tn UNIX 
ASS UNT?) this fumetion atterots to do the work itself. 
memoutS the new size im p€edsize in the current PROC. Dt she 
new size is smaller, it simoly frees the excess storace. ef 
the new size is larger, it attempts to acauire it. If this 


mails, "cesa 1S Called to acquire the soace oy swapping. 
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In all systems, the newly acquired space is cleared. 


Cre Returned Values 
The values returned by this UDC ION are not 


checked. 


de Erros Concitions 
Lf the new storage reauirement is not valid, the 
new space will Mot, be acquired and the function returns. 
This will usually cause the process to terminate abnormally 


because of a nemory management error. 


G. text.c 


lies MS Wocloptt,OS ), zsuaap(p,tf,00s,oss) 


a. Parameters 

In ONIX; tnis funcio 15 called. with three 
arguments. [mn S “and  "SSWinex, vf 15 called with four. 
The first parameter is a pointer to the proc of a process to 
be swapped out of memory. The second parameter is the 
memory free flaa. In UNI? the third parameter is tne 
process image size in 64*o0vte blocks. Im SUNIX and SSUNIX, 
the third and fourth parameters are the sizes of the 


process's data and stack seaments ın 64e0vte blocks. 


De mine t tome | Deserjot von 
lank this tfumet yom allocates Swao soace for 
the process and Swaps reuout, AMS UNTX ard SSUNIX, this 


function allocates sonace only fer those orocesses that do 
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not already have it. In al? systems, memory is freed if the 
memory free flag is set. .This flaq will not be set if this 
function was called by "neworoc" to create a copy of the 
Bakeant process. Im SSUNIX, when this function is called to 
Swap out a Drocess witn shared core, the memory free flag is 
not set if other  memory-sharing processes remain in the 


shared region. 


Co Returned Values 
The values returned by fas function are not 


checked. 


See error, conc) tions , 

If swap srace must be allocated, hut none is 
available, the message "out of swap space" wil} be sent to 
the console and the system will crash. [tian output error 
occurs durina the swap overation, the messace "swap error" 


wil? be sent to the console and the system will crash. 


2. xalloc(ip) 


a. Parameters 
The parameter is a oointer to the incde of the 
text segment tnat 1s to be allocated or located. The 
current process's UVECTOR and PROC and al! TEXTS are imolied 


parameters. 


0% Functional! Description 
This function establishes the snared text 


segment required hy the current process. ifi the Current 


TE 





process does not reauire shared text, this function simply 
returns. If ehe process does. reauıre shared text, this 
function searches the array of TEXTS for a previously 
established TEXT for the reauested segment. Tf one is 
found, its active=process use count 1S incremented. If the 
requested segment is in memory», the TEXTS in=memory count 1s 
incremented. If a TEXT has not been established, an 
unallocated TEXT is located and allocated to the text 
segment. Swac space is allocated for the text secment. The 
current process's adcress space iS increased using "expand" 
to acquire space for the new text segment. The text seament 
is then read into memory and conieaq to the swap space 
allocated for it. The new memory space acquired for the 
text segment is freed using "exoand" ın UNIX and "prfree" in 
SUNIX and SSUNIX. The address of the TEXT is placed in 
petextp in the current PROC and the process iS swapped out 
of memory. When it returns to memory» the newly established 


text segment w1)) return with it. 


Gs Returned Values 
The value returned by this CURE LON 1S mare 


checked. 


Geaeracor Concitions 
bree TEXT must be esStasolasweag and one is nor 
available, the message "out of text" will ve sent to tne 
console and the system will] crash. If Swap space must be 
allocated and none is available, the messaae "out of Swan 


sosce" will ove sent teo the console ang rhe System will 
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crash. 


De 7 page.c 
Paora loc lcr) 


Be Parameters 
The parameter 1s a bointer to a PROC. The TEXT 


pointed to by the PROC is an imelied oarameter. 


D. Functional Descriotion 
This function is present only in SUNIX and 
SSUNIX. It acquires remory space for the process's UVECTOR, 
data seament, stack segment, and, if necessarv, shared text 
segment. Soace for the text seament is acauired only if tne 
text is not resident in main memory. if allocation failse 


all memory space previously allocated is freed. 


EE Returned Values 
If all allocations are successful, the physica! 
block number of the base of the UVECTOR is returned. If any 


allocation fails, a zero is returned. 


Gre Error Concitions 
Ae Carr” valus Of Zero imeatestes an error to tne 


eoler., 


er. prswap(rp) 
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are Parameters 
Pre tiresSt careametér 1S 3 pointer to a PROC. The 


TEXT pointed to by the PROC is an implied parameter, 


Dis Functional Description 
This furction is present only in SUNIX and 
SSUNIX,. It Sosa process s UVECITOR+ data segment, Stack 


segment, and, if necessary, text seament into main memory. 


E Returned Values 
The value returned by this function is port 


checked. 


Se Error Concitions 
O jepur error occurs duriñe the Swap 
ooeration, the message "swao error" is sent to the console 


and the system will crash. 
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PESA REN DIES O MENE ENCAMA RAS 


ARIS ENCA 1, MONOPROGRAMMING 


enair /usr/sys 

sh rpload 

chdir ken 

@on 70 >c slo.c 

co A 

ea, dmr 

ed ıpe.c </usr/bench/edemd >/dev/null 
en@inr /usr/bench 

O rftest.c 

bas tower<towerin>/dev/null 

od /usr/sys/conf/mi5S.s >/dev/nul! 
AY ys r/unx /dev/nu!l 

bar /bin 

sum *>/dev/null 


wait 
chdir /usr/sys/ken 
eres | .0 


chdir /usr/bench 
rm a.out 


B. BENCH 2, MULTIPROGRAMMING 


chdir /usr/sys 

sh rpload% 

Gaaqgir ken 

cC =0 -c sio.c& 

¿A 

eazamr 

ed ipc.c </usr/bench/edemd >/dev/null® 
ener /usr/hench 

cce >00 rftest.c& 

vas tower<towerin>/dev/null2 

od /usr/sys/conf/m35.s ?/dev/nu!!% 
co /usr/unix /dev/null& 

endhr /bin 

sum *>/dev/null]& 

wait 

chdir /usr/sys/ken 

are 5S 1D.0 

apar? /usríbench 

rm 3.0ut 


76 





10. 


eS 


Sie Oreste eer NCES 


Digital Equipment Corporation, PDP-11/45 Processor 
Handbook, 1975- 


Digital Equioment Corporation» PDP=11/34 Processor 
Handbook, 1976. 


Dorta Egui oment Corsooration, “PDP tl Peripherals 


Emery, Fee Weeks The Development of a Partitioned 
Segmented Mermory Manaaer for the UNIY Ogeratinna 
System, Mo. S. Thesis» Naval Postaraduate School; 
1976. 


Gray, P. E., The Design of a System Software/Hardware 
Interface for a Multiprocessor Graphics System, M. 
San nests, Naval Dostaraduate School, 1977, 


MON R. E., Imblementation of an Adaotive Schedulina 
lso dano tor the “MUNTX Userating System, N. S; 
Thesis, Naval Postgraduate School, 1975. 


RPrtchie, D. Mw. and Thomoson, Ker “The UNIX Time=Sharino 
System, Communications of the SEM, v.17, no. 7, De 
365-375, July, 1979, 


Ritchie, D. “., Tne UNIX 1/0 System, Bell Telenhone 
Maboratories, 19755 


Ritchies, D. M., C Peference Manual, Bell Telephone 
Laboratories, 1974. l 


eaae D, My UNIX Assembler Manual, Bel] Teleohone 
Laboratories, 1974. 


Rote mies) De Ma anc Thomoson, er UNIX Programmer's 
Manual, 6th eco, Bell Telephone Laboratories, 1975. 


77 





12. 











ViscO0s Da 
System 
Thesis, 


We, The Desian of an Inter-Processor Support 


for 
Naval 


an Interactive Graphics Fackaqe, 
Postgraduate School, 1976. 


78 


M 


De 





INITIAL DISTRIBUTION 


Defense Documentation Center 
Cameron Station 
Alexandria, Virginia 22314 


Library, Code 0212 
Naval Postgraduate School 
Monterey, California 93940 


Deoartment Chairman», Code 52 
Department of Computer Science 
Naval Postgraduate School 
Monterey, California 93940 


ELST 


Wo. Copies 


e 


Assistant Professor G. L. Barksdale, Coce SéPa l 


Department of Comouter Science 
Naval Postgraduate School 
Monterey, California 93940 


Professor G. A. Rahe, Code 5/Ra 
Department of Computer Science 
Naval Postgraduate Schoo] 
Monterev, California 93940 


Computer Laboratory», Code 5dec 
Department of Computer Science 
Naval Postgraduate School 
Monterey, California 93940 


mimoames M. O'Del!|, USN 
Boo La Moure County (LST 1194) 
FPO, New Yorx 09501 


79 








a 











7 


í 
- 
7 


a 
y 
o 


"i 





172739 


Thesis 
02445 O'Dell 
Cel The development OL 







=anted memory 





Thesis en 172739 
y > O'Dell 


The development of 
a segmented memory 
pennger for ithe 
UNIX operating sys- 
a with app | ications 
a multiported 
memory environment. 





I 


CODE 


i 


m 


mi 





